Figmaイベントレポート / Single Source of Truth (SSOT) for Engineers - Money Forward 河原覚 #ssottokyo
2024.09.09ふみ子です。
先日行われたFigmaのイベント「Single source of truth」に参加しました。
こちらのブログは、河原 覚（かわはら さとる）さんの「デザインシステムの一元化とその運用」についてお話しいただいた一部をまとめたレポートです。
イベントの概要は【Figmaイベントレポート / What Single Source of Truth(SSOT) TOKYO? - Figma】をご確認ください。
デザインシステムのSSOT
河原さんは、デザインシステムのSSOT（Single Source of Truth）の重要性について強調しました。
彼の役職はデザイン室基盤デザイン部のデザインリードであり、Money Forward Cloudのプロジェクトに関わっています。
多様な企業規模に対応するためのデザインシステムを構築しています。
※SSOTとは
『Single source of truth』の略。
単一（Single)、情報(Source)、正確（Truth）の意味があります。
SSOTのスコープ
SSOTはデザインシステムのエンジニアだけでなく、デザインシステムを利用するデザイナーや他のエンジニアも対象としています。
全員が同じ情報源を参照することで、統一されたデザインと実装を目指しています。
デザインコンポーネントのリスク
大元のデザインコンポーネントでミスが発生すると、その影響は複数の部門や複数プロジェクトなど全体に広がります。
単一障害点（SPOF：シングルポイントオブフェイラー）が有ることをリスクとして捉えています。
真の目的：Truthを高める
SSOTの目的は単に一元化することではなく、情報の「真実性」を高めることです。
人間はミスをするものですが、重要なのは そのミスを迅速に修正できる仕組みを持つこと です。
河原さんが語った6つのポイント
ここからは河原さんが話した具体的なノウハウについてです。
1. 命名規則を整備する
- ルールがあることで連携が容易になり、更新もスムーズに行えます。
- 優先順位をつけるために「should」や「must」を使っています。例えば、Money Forwardではルールが決まっているため、変換が容易です。
2. トークンを積極利用する
- 定義可能なものはすべて定義し、更新が確実に伝わるようにします。
- トークンの定義は、例えばJSONファイルを使用し、Variableの更新が実装の更新と連動するようにしているそうです。
3. 編集を制御する
- 編集制限を厳密にし、誤って変更が行われないようにします。
- レイヤーをロックすることで、共有時の誤操作を防ぎます。
4. ライブラリを分割で管理する
- 大きなファイルを一度に編集するのはリスクが高いため、ブランチを使って分割管理します。これにより、同時編集のリスクを軽減します。
- ※こちらに関する詳しいNote：https://note.com/satoru_kawahara/n/nd8c30202d4a5
5. 仕様説明はドキュメントで
- 仕様の履歴管理が容易になるよう、GitHubなどのWikiを利用して振る舞いの記述を行います。
- Devモードやプラグインのズレに対処するための工夫も必要です。
6. Code Connectの可能性
- デザインと実装の整合性を保つために、Figma上でReactコンポーネントを確認できる「Code Connect」を活用します。
- ただし、デザイナーとエンジニアの間で必要な知識の共有が課題となります。
- こちらの活用についてはMoney Forwardでも試行錯誤していると語っていました。
SPOFに向き合うSSOT
SSOTの設計は、間違いを最小限に抑え、迅速に修正できる体制を構築することが目的です。
アップデートの管理や運用設計を通じて、ただ作るのではなく運用の中で設計を進化させることが重要です。
感想
河原さんのノウハウは、デザインシステムの一元化とその運用において非常に参考になるものでした。
データの一元管理や命名規則の整備、編集の制御などは簡単に取り入れられそうと感じる反面、各々の「自己流」が醸成されていると二の足を踏んでしまいそうです…。
統制を行うリードデザイナーの必要性を感じましたし、自身もSSOTを整備していけるよう精進していきます。
貴重なお時間をいただきありがとうございました。
参考
- 河原 覚(かわはら さとる)氏
- Figmaイベント：Single source of truth
